Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/mapify_cli/parallelism_observability.py`:
- Around line 205-208: The `phantom_parallel` branch in
`parallelism_observability.py` is too eager: `skill_reported_concurrent` with
`same_turn_task_count <= 1` should only map to
`DISPATCH_OUTCOME_PHANTOM_PARALLEL` when there is no conflicting in-flight
evidence. Update the Rule 4 check in the dispatch classification logic to also
require `max_in_flight < 2` (or otherwise defer to the Rule 6 `unknown` fallback
when in-flight evidence contradicts the self-report), keeping the behavior
aligned with the existing `skill_reported_concurrent`, `same_turn_task_count`,
and `max_in_flight` rules.

In `@src/mapify_cli/templates_src/map/scripts/map_orchestrator.py.jinja`:
- Around line 2636-2649: The active wave should determine dispatch mode, but the
current logic in get_wave_step() relies only on
select_execution_strategy(branch, project_dir), which can mark
concurrency_allowed true based on any later color group. Update this decision to
inspect the current wave’s own parallelizability before returning
dispatch_mode="concurrent" or concurrency_enabled=True, and keep sequential when
the active wave width is 1 even if another wave is parallel.

In `@src/mapify_cli/templates_src/map/scripts/map_step_runner.py.jinja`:
- Around line 19103-19118: The classifier currently only receives the
group-level base_sha, so mixed worktree bases never trigger the isolation check
in classify_dispatch(). Update the base SHA collection in the step runner to
gather each subtask’s worktree base SHA from the per-subtask records instead of
only _group_data["base_sha"], and keep feeding that list into classify_dispatch
so len(set(base_shas)) can detect mixed bases correctly.
- Around line 17448-17458: The retry path in merge_wave_worktrees is using the
same batch IDs after abort_wave_group has already deleted the group worktrees
and removed the wave_groups entry, so the next attempt has no inputs to merge.
Update the failure handling in the sub_batches loop to avoid retrying with
destroyed inputs: either perform the retry before calling abort_wave_group,
re-dispatch/recreate the actor worktrees before the next merge attempt, or abort
once and propagate the failure. Use merge_wave_worktrees, abort_wave_group, and
the failed/batches_merged bookkeeping to keep the retry flow consistent.
- Around line 15956-15992: Serialize the lifecycle update flow in the worktree
state helper so `seq` is assigned under a single writer lock instead of after a
plain read in the current lifecycle append path. In the block that reads
`state`, mutates `wave_groups[group_key]["lifecycle"]`, computes `max_seq`, and
calls `_write_worktree_state`, add synchronization around the read-modify-write
sequence to prevent two callers from reusing the same sequence number. Keep the
fix localized to the lifecycle event update logic and preserve the existing
monotonic `seq` behavior in the same function.
- Around line 17429-17439: Gate run_concurrent_wave() with
_concurrent_dispatch_enabled() before any batching or merge work so the
default-off execution.concurrent_dispatch config is respected. Add an early
return or error in the run_concurrent_wave flow, near the existing
branch_name/ids_sorted setup, when _concurrent_dispatch_enabled(pd) is false,
and keep the behavior consistent for direct CLI/coordinator calls. Use the
existing symbols run_concurrent_wave, _concurrent_dispatch_enabled, and
_wt_error to locate and implement the check.
- Around line 16115-16124: The terminal-check in the lifecycle sweep is too
permissive because the all(...) expression in the subtask completion logic only
evaluates list-valued lifecycle entries and skips missing or non-list slots.
Update the terminal-event validation in the map_step_runner template so every
declared subtask must be present and have at least one terminal event before
marking the group as terminal, using the existing lifecycle.values() /
all_terminal logic as the place to tighten the check.
- Around line 17338-17358: The abort/cleanup flow in the worktree rollback path
is removing the group entry even when rollback or discard operations may have
failed, which can hide an incorrect HEAD state. In the cleanup logic around
_wt_rollback(base_sha), discard_subtask_worktree, and record_group_lifecycle,
first capture and check the success/failure of rollback and branch cleanup, and
only delete the wave_groups entry after a verified successful rollback to
base_sha. If rollback fails, preserve the group state (including base_sha) so
verify_group_clean can detect the inconsistency.

---

Outside diff comments:
In
`@src/mapify_cli/templates_src/skills/map-efficient/efficient-reference.md.jinja`:
- Line 1: The Codex copy of the map-efficient supporting reference is out of
sync with the Jinja source. Regenerate
src/mapify_cli/templates/codex/skills/map-efficient/efficient-reference.md from
src/mapify_cli/templates_src/skills/map-efficient/efficient-reference.md.jinja,
using the same content as the matching template under
src/mapify_cli/templates/skills/map-efficient/efficient-reference.md.

---

Nitpick comments:
In `@tests/test_concurrent_dispatch_harness.py`:
- Around line 54-59: The module-level sys.path.insert(0, ...) in
test_concurrent_dispatch_harness.py is leaking generated-script precedence into
the entire test session. Update the import setup around _SCRIPTS_PATH and the
map_step_runner import to use a temporary path change or importlib-based loading
under a private module name, then restore sys.path immediately after loading so
later tests do not resolve map_step_runner from the generated scripts path.

In `@tests/test_map_orchestrator.py`:
- Around line 5370-5436: Add a regression test for the active-wave gate where
the first wave is width-1 and a later wave is parallel, using
compute_dispatch_gate and the existing WAVE_REASON_* constants. In
test_vc3_flag_on_isolation_required_concurrent_and_sequential, add a case with
execution_waves like [["ST-001"], ["ST-002", "ST-003"]] and
current_wave_index=0, then assert the result stays sequential and does not
return WAVE_REASON_CONCURRENT_GATED. Keep the focus on
map_orchestrator.compute_dispatch_gate and the wave-reason symbols so the
mixed-wave behavior is locked down.

In `@tests/test_map_step_runner.py`:
- Around line 13609-13614: The retry coverage in map_step_runner is still using
a no-op abort stub, so the test does not reflect the destructive behavior of
abort_wave_group. Update the retry test around _fake_abort (and the related
retry case) to use the real abort path or a fake that actually removes the retry
inputs/worktree state, then assert the retry behavior with that cleanup in
place. Keep the existing merge failure setup via _fake_merge_fail and the retry
assertions, but ensure the abort semantics are exercised realistically.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/mapify_cli/templates_src/map/scripts/map_step_runner.py.jinja`:
- Around line 17565-17577: The retry counter in the abort path is being lost
because abort_wave_group() removes the wave group entry before
_read_worktree_state() can update it. Update the abort/retry flow in
map_step_runner.py.jinja so the attempt count is persisted in a separate state
location or captured before calling abort_wave_group(), then use that saved
value when computing attempts_remaining. Keep the logic tied to
abort_wave_group(), _read_worktree_state(), and _write_worktree_state() so
repeated redispatches continue incrementing correctly across failures.

In `@tests/test_map_step_runner.py`:
- Around line 14483-14489: The test around
map_step_runner.record_group_lifecycle is swallowing the expected OSError
instead of asserting propagation. Replace the try/except in this test with
pytest.raises(OSError) so the call to record_group_lifecycle(gk, "ST-Q01",
"started", branch) explicitly verifies the write error is raised while still
covering the release/finally behavior.
- Around line 14169-14199: The test is reimplementing the dispatch SHA
collection logic instead of exercising the real CLI/helper path. Update this
case in test_map_step_runner.py to invoke the actual runner entrypoint or helper
that uses record_dispatch_actual and then assert on the emitted classification
outcome. Keep the assertion tied to classify_dispatch only as a verification
target, but drive it through the real CLI flow so regressions in per-subtask
worktree record reading are caught.
- Around line 14277-14305: The current test only checks the first failure path
and does not verify that retry state persists across redispatches. Update
test_vc3_attempts_remaining_decrements_with_config_max_retries in
test_map_step_runner.py to exercise two consecutive failing calls for the same
wave group by reusing the same run_concurrent_wave / abort_wave_group flow, then
assert that attempts_remaining decrements again (for example from 1 to 0). Use
the existing map_step_runner symbols run_concurrent_wave, merge_wave_worktrees,
and abort_wave_group to confirm the stateful retry counter survives across
abort/redispatch cycles.

---

Outside diff comments:
In `@src/mapify_cli/templates_src/map/scripts/map_orchestrator.py.jinja`:
- Around line 2645-2663: The active-wave dispatch check is reading StepState
from a path rooted at the current working directory instead of the provided
project_dir, so compute_dispatch_gate can use the wrong step_state.json. Update
the StepState.load path in compute_dispatch_gate to be anchored under
project_dir, and apply the same project_dir-based pathing in
select_execution_strategy where it also loads StepState so concurrency_allowed
is computed from the same repo state.